Proof of concept, Allow conditional introspection #4551
Conversation
working version error test test we are actually using class enable_introspection_entry_points on class itself allow to be set to true
cody-elhard
changed the title
|
Closing, this worked from the perspective of GraphiQL. However it does not prevent a user from running the query |
| @@ -1045,6 +1050,7 @@ def execute(query_str = nil, **kwargs) | |||
| if query_str | |||
| kwargs[:query] = query_str | |||
| end | |||
| enable_introspection_entry_points if kwargs[:enable_introspection_entry_points] | |||
There was a problem hiding this comment.
Unfortunately, this won't play nice with a Fiber- or Thread-based application server (like Puma) because in that case, multiple queries may be running at the same time, using the same schema. If one query disabled entry points on the schema, then another query enabled them again, the first query would use the setting from the second query. (It's a memory conflict: the schema is shared between queries, so it the schema is changed, all currently-running queries would use the modified schema.)
Technically, it would still work in forking servers (like Unicorn), but modifying the Schema class while the application is running would cause it to be copied into fork-specific memory which is slow and a poor use of space. (Although I wouldn't be surprised if some other element of Schema setup causes it to be written into the fork's own heap, so that may not be a new problem...)
|
Here's an approach for implementing something like this using custom introspection: https://gist.github.com/rmosolgo/bd885348da2e39615b0ac55f369ce44c |
This demonstrates one way to enable introspection at runtime. In our case, admin users provided by context should be able to introspect queries to make tools such as GraphiQL useful.
Fix for #4262